1. Field of the Invention
This invention relates in general to the field of instruction processing in computer systems, and more particularly to an apparatus that allows a microprocessor to execute application programs directly from memory, where the application programs are coded using native micro instructions.
2. Description of the Related Art
Microprocessors execute application programs in order to automate certain tasks such as regulating the temperature of a heating element within a coffee maker, controlling the distribution of money from an automated teller machine, or processing numbers on a spreadsheet according to an operator-entered formula on a desktop computer.
The programming instructions used to write application programs for early microprocessors were unique to each particular microprocessor. For example, The Intel® 4004 microprocessor, produced in the early 1970's, had 46 instructions from which a programmer could choose to write application programs. And the programs that were written for the 4004 would only execute on the 4004.
Since the early 1970's, hundreds of different microprocessor designs have been developed. And while many of these microprocessors were original designs, some manufacturers attempted to capture market segments by developing clone microprocessors which were capable of executing application programs that were originally coded to execute on a different microprocessor. The importance of being able to execute “legacy” applications became exceedingly prevalent in the art in 1979 when the Department of Defense (DoD) affirmed its substantial investment in applications programming by issuing MIL-STD-1750, a military standard documenting the high-level design features of a conceptual 16-bit microprocessor for use in all future airborne and weapons systems. MIL-STD-1750 was referred to as an instruction set architecture (ISA) because, in addition to specifying architectural features of a microprocessor such as the types and number of addressable internal registers, it also precisely documented a set of programming instructions to by executed on the conceptual microprocessor. Thus, with the architectural standard already developed by the military, manufacturers were free to design conforming microprocessors that implemented the '1750 architecture using design and manufacturing techniques that optimized their products toward certain desirable features. For instance, one manufacturer could implement the '1750 architecture in such a manner as to maximize the speed of a '1750 microprocessor. Another manufacturer could optimize their product to maximize its resistance to electromagnetic radiation signals. Yet another manufacturer could tailor their product to minimize the cost of the product. And regardless of which features were emphasized by a particular design implementation, each of the '1750 microprocessor implementations were capable of executing application programs that were coded according to the '1750 ISA.
This trend exploded into the commercial marketplace during the 1980's as desktop computers began to proliferate into the business community. As particular application programs gained in popularity, users began to challenge the industry to provide improved and more technologically advanced microprocessors that were still capable of executing these popular software applications. Consequently, microprocessor designers have since focused on providing faster, more robust, more reliable, more power-efficient, and less costly microprocessor designs that are capable of executing both new software and legacy applications. Within the desktop computer industry today, perhaps the most widely used ISA is the Intel® 32-bit ISA. The 32-bit ISA, or x86 ISA, documents hundreds of programming instructions that can be used in a wide variety of addressing forms for processing data within a present day desktop computer. Today, many different manufacturers produce x86-compatible microprocessors. And the design of each of these x86-compatible microprocessors, as was the case for '1750 microprocessors, is tailored to underscore particular features such as complexity, power, speed, or cost.
To implement a physical microprocessor that conforms to a particular ISA, designers today employ a number of techniques, all of which are utterly transparent to an application programmer. Whereas the application programmer is concerned that a conforming microprocessor provides the documented types and number of internal registers, and that the microprocessor is capable of executing ISA instructions according to specification, he/she is generally not aware of how such conforming capabilities are provided. The hardware and internal logic devices documented within an ISA that must be made available for application programming are generally referred to as “architectural resources.” Hardware and logic provided within a microprocessor design to implement these architectural resources in a manner that favors some particular aspect of the design are often called “native resources.” For example, the x86 ISA documents eight architectural internal registers that can be explicitly prescribed by x86 macro instructions. Yet, one skilled in the art will appreciate that a present day x86-compatible microprocessor has hundreds of native registers that are used for a wide variety of purposes. But although the use of native resources in a present day microprocessor is prolific, the exercise of these native resources and the manner in which they are prescribed for use is not typically observable to an application programmer nor can he/she explicitly prescribe their use within an application program. This is because his/her applications are coded using macro instructions according to a particular ISA and the macro instructions do not provide for addressing or employing native registers and other resources.
Consequently, a present day microprocessor executes programs from memory that are coded using macro instructions according to a particular ISA. These macro instructions direct the use of various architectural resources, functions, and features within the microprocessor. But within a few clock cycles of fetching a macro instruction from memory, today's microprocessors translate the macro instruction into a corresponding sequence of native instructions. Native instructions are designed to efficiently and effectively utilize the native resources within the microprocessor to carry out the architectural operations prescribed by the macro instruction. For instance, a macro instruction prescribing a swap of the contents of two architectural registers may be translated into a sequence of three native instructions: a first native instruction that retrieves the contents of a first architectural register and that stores the contents into a native register, a second native instruction that moves the contents of a second architectural register to the first architectural register, and a third native instruction that moves the contents of the native register to the second architectural register.
But whereas functions for exercising architectural resources within a present day microprocessor can be programmed and executed using macro instructions, the same cannot be said for the exercise of native resources. And from the standpoint of a production test engineer or an application programmer, the distinction between native resources and architectural resources in a microprocessor design is somewhat artificial at best: a register is a register after all. In the case of an application programmer, the difference between an architectural register and a native register is that the architectural register can be explicitly prescribed for use by an application program; the native register cannot be explicitly prescribed. And from the perspective of a test engineer, if a register exhibits a failure mode, the microprocessor part must be tagged as a failed part, regardless of whether the register is native or architectural.
Yet, outside of a very small amount of native built in self test (BIST) that is manufactured as an element of a microprocessor, all other application and test programs must be developed using macro instructions because today's microprocessors are only capable of executing programs from memory that are written in macro code. Consequently, any application program or native resource test program must indirectly prescribe native resources through the use of complex and sometimes unintelligible macro code sequences. As a result of the complexity surrounding the development of native resource test programs, an alarming number of deficiencies are resulting following mass distribution of some well-known microprocessor designs, primarily because comprehensive and understandable native resource test programs could not be developed to diagnose anomalies in these designs after they were committed to production. In addition, application programmers are precluded altogether from exercising desirable native resources.
The native architecture of certain microprocessor designs is becoming more well known to those in the art as well as the structure of native instructions that are employed internally to efficiently and expeditiously exercise the native architecture to perform certain functions or to execute certain algorithms.
Therefore, what is needed is a microprocessor whose native resources can be exercised at the application programming level via routines consisting of sequences of native instructions.
It is also desirable that the exercise of these native routines be compatible with the concurrent execution of legacy multi-tasking operating system and application software to include provisions for operating in the presence of interrupts, exceptions, task switches, and other forms of program control transfer to which present day applications are exposed.
Furthermore, what is needed is a microprocessor apparatus that allows native instructions, retrieved from memory, to bypass macro instruction translation functions, thereby allowing the explicit prescription of native resources by an application program.